ddi/tbor/types/tests/harness/mod.rs:36

• This module doc says in-session tests are gated with cfg(not(any(feature = "mock", feature = "sock"))), but the updated command tests (e.g. open_session.rs, psk_change.rs) are no longer gated off under sock and will run there. The documentation should match the actual cfg regime (likely only excluding mock).

//!   on-silicon test runs; the in-session command tests run under
//!   this backend too (they are gated
//!   `#![cfg(not(any(feature = "mock", feature = "sock")))]`, which
//!   admits both `emu` and the no-feature native OS build). The

ddi/tbor/types/tests/commands/open_session.rs:705

• This diagnostic message still references the old test name (open_session_multi_threaded_all_should_open). If the test is renamed to reflect its real assertions, the log prefix should be updated too to avoid confusion when reading CI output.

        eprintln!(
            "open_session_multi_threaded_all_should_open: FW accepted all {MULTI_THREADED_TOTAL} \
             concurrent sessions without emitting any table-full rejection; race between success \
             and rejection branches not exercised at this thread count",
        );

ddi/tbor/types/tests/harness/fixture.rs:111

• open_dev() now unconditionally calls dev.erase(), but the socket backend implements DdiDev::erase as UnsupportedCmd (see ddi/sock/src/dev.rs:301-303). This makes --features sock runs panic during fixture setup, before any tests execute. Consider skipping the erase step for the sock backend (or implementing erase support in the socket transport) so sock tests can run.

    let path = info.path.clone();
    let dev = ddi.open_dev(&path).expect("open test backend device");
    dev.erase()
        .expect("open_dev: factory-reset backend before test");

ddi/tbor/types/tests/harness/fixture.rs:86

• unsafe impl Send for TestDev relies on a non-enforced invariant ("only secondaries are sent across threads"). If a future test accidentally moves a primary TestDev (with _guard: Some(...)) to another thread, dropping it there may violate the mutex’s thread-affinity requirements and turn into UB. A safer pattern is to make the primary/secondary distinction explicit in the type system (e.g., separate PrimaryTestDev / SecondaryTestDev types, or an enum where only the secondary variant is Send) so the compiler enforces the invariant.

#[allow(unsafe_code)]
unsafe impl Send for TestDev {}

ddi/tbor/types/tests/commands/part_init/happy_path.rs:317

• Same issue as part_init_determinism: this test calls ctx.erase() and will fail under --features sock because the socket backend does not support DdiDev::erase (UnsupportedCmd). Gate it off for sock (or implement erase in the socket transport).

#[test]
fn part_init_pta_pub_differs_when_include_fmc_cdi_flag_toggled() {

ddi/tbor/types/Cargo.toml:39

• With the hw-tests opt-in feature removed and no default feature set, cargo test -p azihsm_ddi_tbor_types will now select the native OS backend (real hardware) by default. Combined with the updated fixture doing a factory reset, this can cause surprising/destructive behavior on developer machines and will panic on hosts without a device. Consider restoring an explicit opt-in for hardware runs (or setting an explicit default test backend) so the default cargo test path is non-destructive and does not require silicon.

[features]
# Forward backend selection to the azihsm_ddi facade so the integration
# test binary picks up the right backend. The same tests run across every
# transport — choose one with `--features emu` / `mock` / `sock`.
emu = ["azihsm_ddi/emu"]

ddi/win/src/dev.rs:682

• Same issue as above: NoValidSessionId is currently remapped to TborStatus::SessionNotFound, but for TBOR callers this should preserve the driver-layer scoping signal using TborStatus::FileHandleNoExistingSession (numeric encoding matches the DdiStatus variant).
  ddi/tbor/types/tests/harness/fixture.rs:98
• Doc comment is now inaccurate: the harness is gated out only for --features mock, but this comment says "mock/sock builds gate the whole harness out". Also, open_dev is reachable under --features sock as well.

/// Acquire the test lock, open the configured backend device, and
/// factory-reset it before use. Only reachable under `--features emu`
/// or the no-feature (hw) build — mock/sock builds gate the whole
/// harness out at the crate root.

ddi/tbor/types/tests/harness/fixture.rs:86

• unsafe impl Send for TestDev makes the primary (lock-holding) TestDev movable across threads even though the implementation relies on it staying on the lock-acquiring thread. This invariant isn’t enforced by the type system, so it’s easy for future refactors to accidentally introduce UB. Consider splitting the types (e.g., PrimaryTestDev holding the MutexGuard and SecondaryTestDev without it) so only the secondary handle is Send without unsafe.

// secondaries (with `_guard: None`) are sent into `thread::scope`
// worker threads, and rustc cannot prove that at compile time
// because both variants share the same type.
#[allow(unsafe_code)]
unsafe impl Send for TestDev {}

ddi/win/src/dev.rs:666

• map_ioctl_status_tbor maps the driver’s NoExistingSession (per-file-handle session scoping) to TborStatus::SessionNotFound. This loses the driver-vs-FW distinction and contradicts the doc comment that this helper is a pure FileHandle* type-level remap (and TborStatus does define FileHandleNoExistingSession).

This issue also appears on line 680 of the same file.
ddi/nix/src/dev.rs:723

• map_ioctl_status_tbor currently maps NoExistingSession to TborStatus::SessionNotFound, but TborStatus provides FileHandleNoExistingSession for this driver-layer scoping rejection. Using the FileHandle* status keeps TBOR error typing consistent with the DdiStatus mapping in map_ioctl_status.

            Ok(McrCpGenericIoctlErrorKind::NoExistingSession) => {
                return Err(DdiError::TborStatus(TborStatus::SessionNotFound));
            }

ddi/tbor/types/tests/harness/fixture.rs:99

• The doc comment claims open_dev is unreachable under --features sock, but the test binary includes harness under cfg(not(feature = "mock")), so sock builds do compile and call this harness. This comment is now misleading for readers trying to understand which backends run the integration tests.

/// Acquire the test lock, open the configured backend device, and
/// factory-reset it before use. Only reachable under `--features emu`
/// or the no-feature (hw) build — mock/sock builds gate the whole
/// harness out at the crate root.
///

ddi/tbor/types/Cargo.toml:41

• Removing the hw-tests opt-in feature means the no-feature build now targets the native OS backend and will panic in open_dev() if no physical device/driver is present. That changes the default developer experience for cargo test -p azihsm_ddi_tbor_types on machines without hardware and may also affect CI if any jobs build tests without --features emu/sock. Consider restoring an explicit opt-in (feature or env-gate) for on-silicon runs, or making emu the default feature.

[features]
# Forward backend selection to the azihsm_ddi facade so the integration
# test binary picks up the right backend. The same tests run across every
# transport — choose one with `--features emu` / `mock` / `sock`.
emu = ["azihsm_ddi/emu"]
mock = ["azihsm_ddi/mock"]
sock = ["azihsm_ddi/sock"]

ddi/tbor/types/tests/harness/session_guard.rs:12

• This intra-doc link points to crate::harness::open_dev, but open_dev is no longer re-exported from harness/mod.rs (it now lives in crate::harness::fixture). If rustdoc broken-link warnings are denied in CI, this can fail the build; even if not, it’s misleading to readers.

//! is process-global and the per-test serialisation provided by
//! [`open_dev`](crate::harness::open_dev)'s `TEST_LOCK` only orders
//! execution; it does not clean up leaked slots. The guard